Amazon File Cache คืออะไร – พร้อมวิธีการใช้งาน
บทความนี้แปลมาจากบทความที่เป็นภาษาญี่ปุ่นที่ชื่อว่า [新サービス] Amazon File Cache が一般提供されました โดยเจ้าของบทความนี้คือ คุณ Shibata เป็นคนญี่ปุ่นครับ
เมื่อแปลจากภาษาญี่ปุ่นมาเป็นภาษาไทยแล้วผมได้เรียบเรียงเนื้อหาใหม่เพื่อให้เข้าใจง่ายขึ้น เนื่องจากบางครั้งอาจมีการอัปเดตข้อมูลใหม่ จึงมีความจำเป็นต้องอัปเดตให้เป็นข้อมูลปัจจุบัน
สวัสดีครับ ผม Shibata ครับ
Amazon File Cache เป็นบริการใหม่ที่เปิดตัวในงาน AWS Storage Day 2022 ที่จัดขึ้นในเดือนสิงหาคมปีนี้ ซึ่งได้รับการเผยแพร่อย่างเป็นทางการแล้ว
ดูการเปิดตัวจาก AWS ได้ที่ลิงก์ด้านล่างนี้
บทความนี้ได้อธิบายภาพรวมของ Amazon File Cache
Amazon File Cache คืออะไร
Amazon File Cache เป็นบริการที่ให้บริการ Cache server ที่ให้การ Cache ความเร็วสูงสำหรับ File server
(อ้างอิงรูปภาพจาก AWS Storage Day 2022 Keynote)
Amazon File Cache รองรับ File server ดังนี้
- Amazon S3 Bucket
- NFS Server ที่ให้บริการโดย AWS (สามารถเข้าถึง DNS ผ่าน NFS v3)
- Amazon FSx for OpenZFS
- Amazon FSx for NetApp ONTAP
- NFS Server ของ On-premise Environment (NFS v3)
ประเด็นคือให้ความรู้สึกเหมือนเป็น Bucket หรือ NFS Server ของ NFS v3 แต่ไม่ได้ระบุไว้ว่ารองรับ Amazon EFS หรือไม่
(สำหรับ EFS ดูเหมือนว่าไม่มีทางเลือกนอกจากต้องสร้างสภาพแวดล้อมจริงและตรวจสอบการดำเนินการ...)
และ Client ที่สามารถใช้ Amazon File Cache ได้ ณ วันนี้คือ
- EC2 Instance ที่ติดตั้ง Lustre Client
- Lustre Client จะต้องเป็น Distribution ที่รองรับ
- ECS Container ของ EC2 Host
- ต้องมีการตั้งค่า Luster Client
- ไม่รองรับ Fargate
เมื่ออ่าน Document ของ Amazon File Cache ดูแล้ว ทำให้พบว่าบริการนี้ได้รับการปรับแต่งตาม FSx for Lustre ทำให้มีเงื่อนไขเช่นเดียวกับ FSx for Lustre อยู่ในหลายๆที่
ดังนั้นดูเหมือนว่าจะต้องติดตั้ง Luster Client (Ver.2.12 หรือใหม่กว่า) บน Client ที่ใช้สำหรับครั้งนี้
Region ที่พร้อมใช้งาน
Region ที่พร้อมใช้งานสำหรับ Amazon File Cache ณ วันที่เขียนบทความมีดังนี้
- US East (N. Virginia)
- US East (Ohio)
- US West (Oregon)
- Canada (Central)
- Europe (Frankfurt)
- Europe (Ireland)
- Europe (London)
- Asia Pacific (Tokyo)
- Asia Pacific (Singapore)
- Asia Pacific (Sydney)
ราคา
ดูราคาได้ที่ลิงก์ด้านล่างนี้
Amazon File Cache Pricing
ค่าบริการ Amazon File Cache มีอยู่ 2 ประเภทหลักดังนี้
- ค่าใช้จ่ายการใช้งาน Storage: ค่าใช้จ่ายขึ้นอยู่กับการใช้งาน Cache และ Metadata (หน่วย GB-months คิดตามหน่วยวินาที)
- ปริมาณการถ่ายโอนข้อมูล: ค่าบริการในการถ่ายโอนข้อมูล "เข้า", "ออก" ในกรณีที่ข้าม AZ และ VPC Peering + ค่าบริการในการถ่ายโอนข้อมูล "ออก" ในกรณีที่ข้าม Region
จุดนี้ก็เหมือนกับ FSx for Lustre
แต่สำหรับจุดที่ต้องระวังคือ
- Storage throughput ที่มีประสิทธิภาพสูงมากถึง 1000 MB/s ต่อ TiB
- ปริมาณความจุ Storage ขั้นต่ำของ Amazon File Cache คือ 1.2 TiB (เช่นเดียวกับ FSx for Lustre)
- ราคาต่อหน่วยการใช้ Storage สูงกว่า 2 เท่าของ FSx for Lustre ที่มีอัตราส่วนปริมาณงานเท่ากัน
แนะนำให้ประเมินราคาล่วงหน้าเมื่อมีการใช้งาน เนื่องจากค่าใช้จ่ายการใช้งาน Storage มีแนวโน้มที่จะราคาสูง
ตัวอย่างเช่น ราคา Storage ใน Region Singapore ของ ณ วันที่เขียนบทความ จะอยู่ที่ $1.506 per GB-month ทำให้ถึงแม้จะเลือกความจุขั้นต่ำสุดที่ 1.2TiB (1200GB) ก็ต้องจ่าย $1,807.19 *1ทุกๆเดือนสำหรับแค่ค่า Storage อย่างเดียว ซึ่งถือว่าค่อนข้างแพงเลยทีเดียว
จะมีค่าบริการในการถ่ายโอนข้อมูลเพิ่มเติมตามจริง
การทดสอบ
ครั้งนี้ เราจะมาสร้างสภาพแวดล้อม Cache สำหรับ S3 Bucket และตรวจสอบการทำงาน
ก่อนอื่นผมต้องการตรวจสอบขั้นตอนการใช้งาน ดังนั้นจะไม่ทำการประเมินประสิทธิภาพ
สร้างสภาพแวดล้อม S3 + Amazon File Cache และ EC2 Instance สำหรับตรวจสอบการเชื่อมต่อบน VPC ที่มีอยู่ใน Region Singapore บนบัญชี AWS ที่ใช้สำหรับการตรวจสอบ (Validate AWS account) ของเรา
เราจะใช้ Ubuntu 22.04 แทน Amazon Linux 2 เนื่องจาก Document ถือว่าเป็น Luster Client Ver.2.12 หรือใหม่กว่า
(อย่างไรก็ตาม เมื่อได้ตรวจสอบในภายหลังแล้ว ไม่ว่าจะเป็น Amazon Linux 2, Lustre Client Ver.2.10 ก็ไม่มี Error)
การเตรียม S3
ขั้นแรก ให้เตรียม S3 ก่อน
ครั้งนี้ เราจะมาสร้าง S3 Bucket ชื่อ amazon-file-cache-test-20230106 ใน Region Singapore
- ปิดใช้งาน ACL
- บล็อกการเข้าถึงสาธารณะ
- เปิดใช้งานการเข้ารหัสเริ่มต้น (SSE-S3)
- นอกจากนี้หากใช้ SSE-KMS จะต้องตั้งค่า Bucket policy แยกต่างหาก
ซึ่งเป็น Bucket แบบ Private ที่มีการตั้งค่าน้อยที่สุด
และให้อัปโหลดไฟล์ (hello-world.txt) เพื่อใช้สำหรับทดสอบ
การเตรียม Security Group
Amazon File Cache ต้องตั้งค่า Security Group 1 ตัว เพื่อรับการสื่อสาร Inbound
โปรดทราบว่า Security Group นี้ ต้องเปิด Port Lustre (TCP 988, 1021 - 1023 และ UDP 988, 1021 - 1023) ไม่ใช่ Port NFS (TCP 2049, UDP 2049)
แล้วถ้าหากทำการตั้งค่า Security Group ไม่ถูกต้อง Error message ต่อไปนี้จะปรากฏขึ้นตอนสร้างสภาพแวดล้อม
The file cache cannot be created because the default security group in the subnet provided or the provided security groups do not permit Lustre LNET network traffic on port 988
การสร้าง Amazon File Cache
เราจะสร้าง Amazon File Cache ในขั้นตอนนี้
Amazon File Cache ถือเป็นส่วนหนึ่งของ Amazon FSx บน AWS Management Console
เลือก Caches ที่เมนูด้านซ้ายจากหน้าจอหลักของ Amazon FSx แล้วคลิก Create cache
Step 1 - Specify cache details
ขั้นแรกให้ระบุชื่อ Cache กับความจุของ Storage และระบุ Subnet ที่จะวาง Cache
ความจุของ Storage จะระบุระหว่าง 1.2 TiB - 2.4 TiB โดยเพิ่มขึ้นทีละ 1.2TiB หรือ 2.4TiB (2.4,4.8,7.2...) และ Throughput capacity จะถูกตั้งค่าโดยอัตโนมัติ *2ตามความจุ
การระบุ Subnet จะดำเนินการตามสภาพแวดล้อม และระบุสิ่งที่สร้างขึ้นก่อนหน้านี้ใน Security Group
Encryption (การเข้ารหัส) ของ Storage จำเป็นต้องมี
ครั้งนี้จะเลือก Encryption key ค่าเริ่มต้น
Step 2 - Link data repositories
เมื่อมาหน้านี้จะเป็นการตั้งค่าของ Cache source (Link data repositories)
มีช่องให้เลือก Repository เราสามารถเลือก NFS หรือ S3 ก็ได้
ครั้งนี้เราจะเลือก S3 และจะตั้งค่าเนื้อหาต่อไปนี้
- Data repository path : Bucket URL
s3://amazon-file-cache-test-20230106/ - Cache path : Path ที่ต้องการ (ครั้งนี้คือ
/s3test)
Amazon File Cache สามารถ Cache ได้จาก S3 Bucket หลายตัว และ Cache path คือ Path สำหรับแบ่ง Root ในขณะนั้น
เมื่อคลิกปุ่ม Add เนื้อหาที่ป้อนจะถูกเพิ่มลงในช่อง Data repository associations ที่ด้านบนหน้าจอ
Step 3 - Review and create
เมื่อเสร็จสิ้นการตั้งค่าที่จำเป็นแล้ว ให้ตรวจสอบเนื้อหาที่ป้อนก่อนหน้านี้เพื่อไม่ให้มีความผิดพลาด แล้วคลิก Create cache ด้านล่าง
การสร้าง Cache จะเริ่มต้นขึ้น ให้รอจนกว่าจะเสร็จสิ้น
ครั้งนี้เสร็จสิ้นในเวลาประมาณ 10 นาที
เมื่อเปิดหน้าจอรายละเอียด ก็จะแสดงเป็นแบบนี้
Cache type คือ Lustre version 2.12
เมื่อสร้าง Cache แล้ว จะมี DNS name ที่สามารถอ้างอิงจาก DNS (Route 53 Resolver) ของ VPC ได้ และชื่อนี้กับ Mount name จำเป็นสำหรับการใช้งานจาก Client
สำหรับแต่ละแท็บที่ด้านล่างของหน้าจอมีลักษณะดังนี้
อันแรก Network ＆ security เป็นข้อมูลตำแหน่ง Network
ต่อไป Monitoring เราสามารถตั้งค่า CloudWatch alarms และตรวจสอบสถานะการทำงานได้ที่นี่
ต่อไป Administration เราสามารถเปลี่ยนเวลา Weekly maintenance window ได้ที่นี่
ต่อไป Data repositories มีลักษณะดังนี้ และข้อมูลของ Cache source repository จะแสดงขึ้นมา
สุดท้าย Tags คือช่อง Maintenance ของ Tag
นอกจากนี้ เมื่อคลิกปุ่ม Attach จะแสดงขั้นตอนการเชื่อมต่อจาก Client เป็น Pop-up ตามรูปภาพด้านล่าง
เพิ่มเติม: เกี่ยวกับ DNS name และ ENI
DNS name ถูกลงทะเบียนใน DNS (Route 53 Resolver) และเมื่อตรวจสอบเนื้อหาแล้ว Private IP จะถูกส่งกลับมาดังนี้
กรณีที่ต้องการใช้จากภายนอก VPC จะต้องมี Route 53 Resolver inbound endpoint เพราะไม่ใช่ public record
# สามารถตอบกลับได้จาก DNS ของ VPC เท่านั้น $ dig fc-0a9573xxxxxxxxxxx.fsx.ap-southeast-1.amazonaws.com +short 192.168.11.141
นอกจากนี้ ด้วยเหตุผลบางอย่าง 5 ข้อ พอตรวจสอบดูแล้วผมคิดว่า "ควรมี ENI หนึ่งรายการสำหรับ Amazon File Cache" จากผลลัพธ์ข้างต้น
หนึ่งข้อที่ทราบคือเป็นสิ่งที่ใช้ใน DNS name แต่ไม่ทราบการนำไปใช้ของอีก 4 ข้อที่เหลือ
ตามที่คาดไว้ ผมคิดว่ามันอาจจะถูกใช้เพื่อเข้าถึง Cache source เมื่อใช้ NFS เป็น Cache source
การเตรียม EC2
เมื่อเตรียม Cache เสร็จแล้ว ต่อไปเรามาเตรียม EC2 กัน
เนื่องจากขั้นตอนของ Document ตามที่กล่าวมาข้างต้น ใช้ Ubuntu 22.04 ดังนั้นครั้งนี้จึงเตรียมสภาพแวดล้อม Ubuntu ตามนี้
ดูตัวอย่างการสร้าง Ubuntu บน EC2 ได้ที่ลิงก์ด้านล่างนี้ (ตัวอย่างนี้เป็นเวอร์ชัน 20.04 ตอนสร้างให้เลือกเวอร์ชัน 22.04 ซึ่งเป็นเวอร์ชันล่าสุด ณ วันที่เขียนบทความนี้)
เข้ามาที่ EC2 Instance ที่สร้างเสร็จแล้ว และทำการ Update kernel และติดตั้ง Lustre Client ตามขั้นตอนด้านล่างนี้
# กรณีของ Ubuntu 22.04
$ cat /etc/os-release | grep PRETTY_NAME
PRETTY_NAME="Ubuntu 22.04.1 LTS"
# การลงทะเบียน AWS Lustre client Ubuntu repository
wget -O - https://fsx-lustre-client-repo-public-keys.s3.amazonaws.com/fsx-ubuntu-public-key.asc | gpg --dearmor | sudo tee /usr/share/keyrings/fsx-ubuntu-public-key.gpg >/dev/null
sudo bash -c 'echo "deb [signed-by=/usr/share/keyrings/fsx-ubuntu-public-key.gpg] https://fsx-lustre-client-repo.s3.amazonaws.com/ubuntu jammy main" > /etc/apt/sources.list.d/fsxlustreclientrepo.list && apt-get update'
# กรณีที่ Kernel version เก่ากว่า 5.15.0.1020-aws ให้อัปเดต Kernel ก่อน
uname -r
# ครั้งนี้เป็น 5.15.0-1026-aws ดังนั้นไม่ต้องอัปเดต + รีสตาร์ท แต่ถ้าเก่ากว่า 5.15.0.1020-aws ให้อัปเดต + รีสตาร์ท ตามด้านล่างนี้
# ※Lustre Client ได้รับการติดตั้งพร้อมกับการอัปเดต Kernel
sudo apt install -y linux-aws lustre-client-modules-aws && sudo reboot
# กรณีที่อัปเดต + รีสตาร์ท ผลลัพธ์ 5.15.0-10xx-aws → อัปเดตเป็น 5.15.0-1026-aws
ยกเว้นมีการระบุ Kernel version เพื่อใช้ Lustre Client ซึ่งเป็นขั้นตอนง่ายๆ
ผลลัพธ์หลังการติดตั้งจะเป็นแบบนี้
# ตรวจสอบการทำงานเกี่ยวกับ Lustre
$ dpkg -l | grep lustre
ii lustre-client-modules-5.15.0-1026-aws 2.12.8-1fsx6 amd64 Lustre Linux kernel module (kernel 5.15.0-1026-aws)
ii lustre-client-modules-aws 5.15.0.1026.24 amd64 Lustre kernel modules for Amazon Web Services (AWS) systems.
ii lustre-client-utils 2.12.8-1fsx6 amd64 Userspace utilities for the Lustre filesystem (client)
# ตรวจสอบ Version ที่ติดตั้ง
$ lfs --version
lfs 2.12.8การตรวจสอบการเชื่อมต่อ
ต่อไปเรามาตรวจสอบการเชื่อมต่อกัน
รันคำส้่ง mount ในขั้นตอนถัดไปบนคอนโซล EC2
# (Optional) สร้าง mount directory
sudo mkdir -p /mnt
# รันคำสั่ง mount
sudo mount -t lustre -o relatime,flock fc-0a9573xxxxxxxxxxx.fsx.ap-southeast-1.amazonaws.com@tcp:/ms5xxxxx /mntการระบุคำสั่ง mount สามารถคัดลอกและวางสิ่งที่แสดงใน "Attach" ของ Management console ได้
เมื่ออธิบายตามแบบฟอร์มก็จะเป็นดังนี้
# ระบุ -t lustre และต้องเป็น DNS name และ Mount name sudo mount -t lustre -o relatime,flock "DNS name"@tcp:/"mount name" "mount point"
คำสั่ง mount ถ้าเสร็จสิ้นโดยไม่มี Error ก็ถือว่าสำเร็จ
หลังจากนั้น ถ้าทำการเข้าถึง mount point (ครั้งนี้คือ /mnt/) ก็จะเข้าถึง Cache ได้อย่างโปร่งใส
# "Cache pass" แนบอยู่ใต้ mount point
$ ls /mnt/
s3test
# ภายใต้ Cache pass เป็น S3 Bucket และสามารถอ้างอิงไฟล์ที่มีอยู่ใน Bucket ได้
$ ls /mnt/s3test/
hello-world.txt
# สามารถอ้างอิงเนื้อหาในไฟล์ได้
$ cat /mnt/s3test/hello-world.txt
Hello Amazon File Cache!
อย่างไรก็ตาม ผลลัพธ์ของคำสั่ง df จะเป็นแบบนี้
$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 7941576 1930584 5994608 25% /
tmpfs 228328 0 228328 0% /dev/shm
tmpfs 91332 824 90508 1% /run
tmpfs 5120 0 5120 0% /run/lock
/dev/nvme0n1p15 106858 5329 101529 5% /boot/efi
tmpfs 45664 4 45660 1% /run/user/1000
192.168.11.141@tcp:/ms5jjbmv 1201382912 10240 1201370624 1% /mnt
ถ้าตั้งค่าสิทธิ์การเข้าถึงของ Directory ที่ mount แล้ว เราจะสามารถเขียนได้ตามปกติ
# ลืมตั้งค่าสิทธิ์การเข้าถึงที่เรียบง่าย...
# ※เดิมทีผมรู้สึกว่า mount -o rw ดีกว่า แต่เนื่องจากเป็นการตรวจสอบการทำงาน ดังนั้นก็จะทำตามนี้...
$ chmod 777 /mnt/s3test/
# ถ้าเรามีสิทธิ์ในการเขียน เราสามารถสร้างไฟล์ใหม่ได้ตามปกติ
$ sudo echo "write test" > /mnt/s3test/write-test.txt
# เราสามารถอ้างอิงจาก local ได้ทันที
$ cat /mnt/s3test/write-test.txt
write test
อย่างไรก็ตาม ไฟล์ที่เขียนจะไม่ถูกปรับเปลี่ยนใน Cache source ในทันที และดูเหมือนว่าต้อง Export ด้วยคำสั่ง lfs hsm_archive
รันคำสั่ง lfs hsm_archive ในไฟล์ที่ต้องการและถ้าเสร็จสิ้นโดยไม่มี Error ไฟล์จะถูกเพิ่มไปยัง S3 Bucket
# Export ไฟล์ที่ต้องการไปยัง Cache source (S3 Bucket)
$ sudo lfs hsm_archive /mnt/s3test/write-test.txt
# ตรวจสอบผลลัพธ์
$ sudo lfs hsm_state /mnt/s3test/write-test.txt
/mnt/s3test/write-test.txt: (0x00000009) exists archived, archive_id:1
เพิ่มเติม: เกี่ยวกับเส้นทางการเข้าถึงไปยัง S3
ครั้งนี้เนื่องจากเป็น subnet ที่วาง Amazon File Cache ไว้ใน Private subnet ที่ปิดโดยสมบูรณ์ที่ไม่มีทั้ง NAT Gateway และ VPC Endpoint (Gateway) แต่เราก็สามารถใช้งานได้โดยไม่มีปัญหา
ดูเหมือนว่าการเข้าถึง S3 นั้นทำได้จากพื้นที่ AWS Managed
การลบ Cache
เนื่องจากการตรวจสอบการทำงานเสร็จแล้ว ก็จะลบ Cache ในตอนท้าย
เลือกไฟล์ Cache ที่ต้องการลบ แล้วคลิก Actions และเลือก Delete cache
แล้ว Pop-up ยืนยันจะแสดงขึ้นมา ให้ป้อน Cache ID แล้วคลิก Delete แล้วกระบวนการลบจะเริ่มขึ้น
ให้รอสักครู่จนกว่าจะลบออกเสร็จสมบูรณ์
อื่นๆ
การตรวจสอบการทำงานสิ้นสุดแล้ว แต่หลังจากที่ได้อ่าน Document แล้วอยากจะแนะนำบางจุดที่น่าสนใจ
1. กรณีที่ใช้ On-premises NFS server
ข้อกำหนดเบื้องต้นในกรณีที่ใช้ NFS server ของ On-premise environment เป็น Cache source มีอธิบายอยู่ในลิงก์ด้านล่าง
เมื่อเลือกบางประเด็นสำคัญจากที่นี่
- ต้องเป็น NFS v3
- การเข้าถึงฝั่ง On-premise ต้องเป็น Private network ที่สอดคล้องกับ RFC 1918
- IP ที่สามารถเข้าถึงได้จาก Amazon File Cache และต้องเป็น Host name ที่สามารถจำแนกชื่อได้
- On-premise environment และ VPC ต้องถูกเชื่อมต่อผ่าน Direct Connect หรือ Site-to-Site VPN
โปรดทราบว่า On-premise environment และ VPC จะต้องเชื่อมต่อกับ Private
2. Performance
บางทีทุกคนที่ดูบทความนี้ก็ต้องการทราบข้อมูลของ Performance ด้วย ดังนั้นผมจะแปะลิงก์ไว้ด้านล่างนี้
3. Maintenance window
Amazon File Cache ยังมี Weekly maintenance window เช่นเดียวกับ FSx series อื่นๆ
ตาม Document
Patching occurs infrequently, typically once every several weeks. Patching should require only a fraction of your 30-minute maintenance window. During these few minutes of time, your cache will be temporarily unavailable.
ระหว่างการ Maintenance ในช่วงเวลาไม่กี่นาทีนี้ ดูเหมือนว่าเราอาจจะไม่สามารถเข้าถึง Cache ได้
สุดท้ายนี้
ครั้งนี้ผมได้ทำการตรวจสอบการทำงานให้ดูเป็นตัวอย่าง
โดยส่วนตัวแล้วผมไม่มีสภาพแวดล้อมที่ดีและยากที่จะตรวจสอบ ดังนั้นผมจึงมอบความไว้างใจให้กับบริการ AWS
หมายเหตุ
ผมหวังว่าบทความนี้จะเป็นประโยชน์ให้กับผู้อ่านได้นะครับ
แปลโดย: POP จากบริษัท Classmethod (Thailand) ครับ !
